In any enterprise, data regarding aspects thereof is accumulated over time. This data can be used to report the status of the enterprise. For example, with regard to a sales enterprise, sales data can be accumulated pertaining to each sale of a product, including the salesman, the customer, the region of the salesman, the region of the customer, the amount of the sale, the quantity of the product sold, the date of the sale, the date of the delivery of the sold product, and so on. Based on such sales data, then, it may be that a report is generated that details sales by year, by month, by customer by year, by product by quarter, by salesman by delivery date, by region by week, etc.
The data that populates a report will typically be accumulated in a data source, such as a database. A data source, as the term is used here, is a storehouse for digitally recorded data. In order to filter the data in a data source into properly organized columns and rows for a report, a report designer may specify, in a report definition, the particular data that is desired from a data source. For example, a report designer might specify that he wants a “salesman name” in the first column of a report.
The report designer may then write a program that recognizes the field indicated for the first column of a report definition (salesman name), queries a data source for all salesman names, and places them, one after the other, in the first column of a report. Instead of writing his own program to carry out this task, the report designer may use commercial reporting software that provides this function. Such software may allow a report designer to simply specify, in a report definition, a type of data he wants in the various columns and/or rows of a report. The commercial software will then automatically analyze the report definition, query a database, and place the desired data in a report.
FIG. 5a and FIG. 5b provide a simple example of a report definition and a corresponding report. The exemplary report design in FIG. 5a provides a salesman column 501, a 1990 sales column 502, and a total sales column 503. This exemplary report design may be submitted to commercial reporting software that can pull the specified data from one or more data sources and format the data appropriately for a report such as that of FIG. 5b. FIG. 5b shows a populated salesman column 501aa, a populated 1990 sales data column 502aa, and a populated total sales column 503aa. 
A more accurate view of a report definition is provided in FIG. 1b. A report definition, or report definition file 140 will typically specify a report layout 140a and a query 140b. The query 140b provides the data that is desired for a report, while the layout 140a gives the way in which the data will be presented in a report. In other words, the layout provides the graphical representation of a report on a display surface. Thus, the report definition in FIG. 5a can be understood as a graphical representation of a layout 140a and a query 140b of a report definition 140. The presentation of the three side-by side boxes could represent to hypothetical report generation software that three columns are to be generated. The contents of each box—501, 502, 503 could provide the query results that are to be placed in each column. A report definition may thus be represented graphically. It may also be represented by any other means of describing the layout and contents of a report. For example, a mark-up language such as the extensible markup language (XML) may be used to declare the various layout properties and data contents of a report. Thus a report definition file may be an XML file.
FIG. 1a provides a high-level view of exemplary report processing software 110 for populating a report definition 100 with appropriate data. The report processing software 110 may comprise a plurality of data extensions 111 for properly interpreting data stored in any of a plurality of data sources 120, 121. The report processing software 110 may also comprise a number of rendering extensions 112. The rendering extensions 112 convert generated reports into appropriate file formats, e.g. Hyper-Text Markup Language (HTML) 130, Extensible Markup Language (XML) 131, or some other file format 132. A process (not shown) capable of reading the formatted output files 130, 131, 132 can then display the report through a Graphic User Interface (GUI). In summary, a report definition 100 is used by the report processing software 110 to identify the data to be gathered from data sources 120, 121 and compile the data into a properly structured report. The software 110 may generate a report in any file format 130, 131, 132. This process is also described in U.S. patent application Ser. No. 10/400,734, which is hereby incorporated by reference in its entirety.
Those who design reports want flexibility in the ways they can organize and present a report. Thus, modern commercial reporting software typically supports a variety of report layouts. Two of the primary report layouts common today are the table and the matrix. A table layout is depicted in FIG. 5b, while an exemplary matrix layout is depicted in FIG. 6a. Note how the matrix is characterized by an empty corner cell, usually in the top left region of the report, while the table has no empty corner cell. Both layouts are characterized by columns arranged along a horizontal axis and rows arranged along a vertical axis.
While table and matrix report layouts are common, and thus commonly supported by commercial reporting software, a host of additional layouts are often desired. FIG. 6b provides just one example of a potentially unsupported report layout. The report layout of FIG. 6b dynamically changes from a horizontal layout 660 to a vertical layout 670 depending on how much data there is. When there are only four data entries, 650, 651, 652, and 653 for the report, the horizontal layout 660 is used, but when there are over four entries, e.g. 650, 651, 652, 653, 654, 655, and 656, a vertical layout 670 is desired. Using city names in and around Washington State, the exemplary report of FIG. 6b might appear as either of the following:
Small Amount of Data:
SeattleSpokaneTacomaBellevueLarge Amount of Data:
SeattleSpokaneTacomaBellevueVancouverWalla WallaSnohomishKennewickPascoMoses Lake
One could imagine a situation in which such a layout is desired. Similarly, one might imagine the report definition file for such a report. It would specify the various layout properties of the report, including the dynamic change property, and the data to place within the various layout properties. Unfortunately, modern report processing software may not, and likely will not, support the layout of FIG. 6b, and may similarly fail to support many other custom report layouts. While report processing software may support a wide range of layouts, there are near infinite possibilities for reporting layouts that may be desired. Commercial reporting software may attempt to support as many practical layouts as possible, but will inevitably fall short of customer needs in some settings.
The solution for those who wish to create a report with a custom layout has traditionally been to write custom software to generate the desired report. Needless to say, this can be somewhat more painstaking than using commercial reporting software. It is a barrier to creating custom report layouts that may frequently result in a report designer making do with one or more layouts that are supported by his or her commercial software. Thus, a designer may choose a layout that is “second best” for his or her desired report. Alternatively, if a report designer is determined to Write a program to support a desired layout, he or she will have to make do without the many additional features provided by commercial reporting software.
FIG. 3 provides a more detailed view of typical commercial reporting software 310. A plurality of supported report layouts 340 may be used with the software 310, while the many unsupported report layouts 350 are not available for use with the software. The software 310 includes a variety of features 360 that facilitate the creation of reports. Features 360 may include, for example, functions that facilitate insertion of desirable properties such as colors, drillthroughs, show/hide, and so on. There are a host of such features 360 available in modern commercial reporting software 310, and an exhaustive list is not helpful here. These features 360 are not available to those who write custom software to support a custom report definition.
Typical commercial reporting software 310 may also include the nuts and bolts processes 370 for building reports of the various supported layouts 340. These processes 370 may draw upon a set of report building components 380 that provide readily available report properties for insertion into reports. Because reports are typically destined to be rendered in a Graphic User Interface (GUI), the components 380 may be configured such that they recognizable to the rendering extensions 312. Exemplary building components 380 may be anything that is useful in generating a report, such as a process for generating a text box, process for generating an image, processes for drawing circles, creating columns, and so on.
In light of the current state of the art in commercial reporting software, there is a heretofore unrecognized need to provide support for custom report layouts in commercial reporting software.